Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# Resynchronizing the Recovery Catalog

When RMAN performs a resynchronization, it compares the recovery catalog to either the current control file of the target database or a backup control file and updates the recovery catalog with information that is missing or changed. When resynchronizing, RMAN does the following:

1. Creates a snapshot control file.

2. Compares the recovery catalog to the snapshot control file.

3. Updates the recovery catalog with missing or changed information.

RMAN performs resynchronizations automatically as needed when you execute certain commands, including `BACKUP`. You can also manually perform a full resynchronization using the `RESYNC CATALOG` command.

## Types of Records Updated When Recovery Catalog is Resynchronized

Table 10-2, "Records Updated During a Resynchronization" describes the types of records that RMAN resynchronizes.

Table 10-2 Records Updated During a Resynchronization

Records | Description
--- | ---
Log history | Created when an online redo log switch occurs.
Archived redo logs | Associated with archived logs that were created by archiving an online log, copying an existing archived redo log, or restoring an archived redo log backup set. RMAN tracks this information so that it knows which archived logs it should expect to find.
Backup history | Associated with backup sets, backup pieces, proxy copies, and file copies. The `RESYNC` `CATALOG` command updates these records when a `BACKUP` command is executed.
Incarnation history | Associated with database incarnations.
Physical schema | Associated with datafiles and tablespaces. If the target database is open, then undo segment information is also updated. Physical schema information in the recovery catalog is updated only when the target has the current control file mounted. If the target database has mounted a backup control file, a freshly created control file, or a control file that is less current than a control file that was seen previously, then physical schema information in the recovery catalog is not updated. Physical schema information is also not updated when you use the `RESYNC` `CATALOG` `FROM` `CONTROLFILECOPY` command.

## Full and Partial Resynchronization

Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed information about new backups, new archived logs, and so forth. However, RMAN does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments (only if the database is open), and online redo logs. In a full resynchronization, RMAN updates all changed records, including those for the database schema.

Note: Although RMAN performs partial resynchronizations when using a backup control file, it does not perform full resynchronizations. A backup control file may not have correct information about the database physical schema, so a full resynchronization could update the recovery catalog with incorrect information.

Note: You can use Oracle Enterprise Manager to perform catalog resynchronizations.

See Also: Oracle Database Backup and Recovery Reference for more information about the `RESYNC` command

## When to Resynchronize the Recovery Catalog

RMAN automatically performs full or partial resynchronizations in most situations in which they are needed. Most RMAN commands such as `BACKUP`, `DELETE`, and so forth perform a full or partial resynchronization (depending on whether the schema metadata has changed) automatically when the target database control file is mounted and the recovery catalog database is available. Thus, you should not need to manually run `RESYNC` `CATALOG` very often.

The following sections describe situations in which a manual resynchronization is required.

### Resynchronizing After the Recovery Catalog is Unavailable

If the recovery catalog is unavailable when you issue RMAN commands that cause a partial resynchronization, then open the catalog database later and resynchronize it manually with the `RESYNC` `CATALOG` command.

For example, the target database may be in New York while the recovery catalog database is in Japan. You may not want to make daily backups of the target database in `CATALOG` mode, to avoid depending on the availability of a geographically distant database. In such a case you could connect to the catalog as often as feasible (for example, once each week) and run the `RESYNC` `CATALOG` command.

### Resynchronizing in ARCHIVELOG Mode When You Back Up Infrequently

Assume that you do the following:

- Run the database in `ARCHIVELOG` mode

- Back up the database infrequently (for example, hundreds of archive logs are archived between database backups)

- Generate a high number of log switches every day (for example, 1000 switches between catalog resynchronizations)

In this case, you may want to manually resynchronize the recovery catalog regularly because the recovery catalog is not updated automatically when a redo log switch occurs or when a redo log is archived. The database stores information about log switches and archived redo logs only in the control file. You must periodically resynchronize in order to propagate this information into the recovery catalog.

How frequently you need to resynchronize the recovery catalog depends on the rate at which the database archives redo logs. The cost of the operation is proportional to the number of records in the control file that have been inserted or changed since the previous resynchronization. If no records have been inserted or changed, then the cost of resynchronization is very low; if many records have been inserted or changed, then the resynchronization is more time-consuming.

### Resynchronizing After Physical Database Changes

Resynchronize the recovery catalog after making any change to the physical structure of the target database. As with redo log archive operations, the recovery catalog is not updated automatically after physical schema changes, such as adding or dropping tablespaces, adding datafiles to a tablespace, or adding or dropping rollback segments.

## Forcing a Full Resynchronization of the Recovery Catalog

Use `RESYNC` `CATALOG` to force a full resynchronization of the recovery catalog.

1. Connect RMAN to the target and recovery catalog databases, and then mount or open the target database if it is not already mounted or open:

       STARTUP MOUNT;

2. Run the `RESYNC` `CATALOG` command at the RMAN prompt:

       RESYNC CATALOG;

   See Also: Oracle Database Backup and Recovery Reference for `RESYNC` `CATALOG` command syntax

## Resynchronizing the Recovery Catalog and CONTROL_FILE_RECORD_KEEP_TIME

If you maintain a recovery catalog, then use the RMAN `RESYNC` `CATALOG` command often enough to ensure that control file records are propagated to the recovery catalog before they are reused.

Make sure that `CONTROL_FILE_RECORD_KEEP_TIME` is longer than the interval between backups or resynchronizations. Otherwise, control file records could be reused before they are propagated to the recovery catalog. An extra week is a safe margin in most circumstances.

Caution: Never set `CONTROL_FILE_RECORD_KEEP_TIME` to `0`. If you do, then backup records may be overwritten in the control file before RMAN is able to add them to the catalog.

See Also: Oracle Database Backup and Recovery Basics to learn how to monitor the overwriting of control file records